第 9 章：Gateway 管理對外服務

除了直接使用 Service 和 Ingress 之外，Kubernetes 社區還發起了 Gateway API 項目，它可以幫助我們將 Kubernetes 中的服務暴露到集群外。

Gateway API 是一個由 SIG-NETWORK 管理的開源項目。該項目的目標是在 Kubernetes 生態系統中發展服務網絡 API。Gateway API 提供了暴露 Kubernetes 應用的資源——GatewayClass、Gateway、HTTPRoute、TCPRoute 等。

Gateway API 已經得到了大量的網關和服務網格項目支持，請在 Gateway 官方文檔中查看支持狀況。

Gateway 目標

Gateway API 旨在通過提供表現性的、可擴展的、面向角色的接口來改善服務網絡，這些接口由許多廠商實現，並得到了業界的廣泛支持。

Gateway API 是一個 API 資源的集合 —— GatewayClass、Gateway、HTTPRoute、TCPRoute 等。使用這些資源共同為各種網絡用例建模。

下圖中展示的是 Kubernetes 集群中四層和七層的網絡配置。從圖中可以看到通過將這些資源對象分離，可以實現配置上的解耦，由不同角色的人員來管理，而這也是 Gateway API 的相較於 Ingress 的一大特色。

Gateway API 與 Ingress 有什麽不同

Ingress 的主要目標是用簡單的、聲明性的語法來暴露 HTTP 應用。Gateway API 暴露了一個更通用的代理 API，可以用於更多的協議，而不僅僅是 HTTP，並為更多的基礎設施組件建模，為集群運營提供更好的部署和管理選項。

Gateway 相較於 Ingress 做了哪些改進

以下是 Gateway API 對 Ingress 的改進點。

• 更具表現力
  • Gateway 表達了更多的核心功能，比如基於頭的匹配、流量加權和其他功能，而這些功能在 Ingress 中只能通過自定義方式實現。
• 更具擴展性
  • Gateway API 允許在 API 的各個層次上鏈接自定義資源。這就允許在 API 結構的適當位置進行更精細的定制。
• 面向角色
  • 它們被分離成不同的 API 資源，這些資源映射到 Kubernetes 上運行應用程序的常見角色。
• 通用性
  • 這不是一種改進，而是應該保持不變。正如 Ingress 是一個具有眾多實現的通用規範一樣，Gateway API 被設計成一個由許多實現支持的可移植規範。
• 共享網關
  • 它們允許獨立的路由資源綁定到同一個網關，從而實現負載均衡器和 VIP 的共享。這允許團隊安全地共享基礎設施，而不需要直接協調。
• 類型化後端引用
  • 通過類型化後端引用，Routes 可以引用 Kubernetes 服務，也可以引用任何一種被設計為 Gateway 後端的 Kubernetes 資源。
• 跨命名空間引用
  • 跨越不同 Namespaces 的路由可以綁定到網關。這樣，盡管對工作負載進行了命名空間劃分，但仍可共享網絡基礎設施。
• 類
  • GatewayClass 將負載均衡實現的類型形式化。這些類使用戶可以很容易和明確地了解資源模型本身有什麽樣的能力。

在了解了 Gateway API 的目的後，接下來我們再看下它的資源模型、請求流程、TLS 配置及擴展點等。

角色劃分

Gateway API 開發者為其使用場景定義四類角色：

• 基礎設施提供方：如 AWS、GKE 等
• 集群運維：管理整個集群的計算、存儲、網絡、安全等
• 應用程序開發者：為自己開發的應用負責，管理應用的健壯性
• 應用管理員：不是所有的公司都有，通常在一些覆雜系統中會有專門的應用管理員 Gateway API 通過 Kubernetes 服務網絡的面向角色的設計在分布式靈活性和集中控制之間取得了平衡。使得許多不同的非協調團隊可以使用共享網絡基礎設施（硬件負載均衡器、雲網絡、集群托管代理等），所有團隊都受集群運維設置的策略約束。下圖展示了在進行 Gateway 管理時的角色劃分。

集群運維人員創建從 GatewayClass 派生的 Gateway 資源。此 Gateway 部署或配置它所代表的底層網絡資源。通過 Gateway 和 Route 之間的路由附加進程 ，集群運維人員和特定團隊必須就可以附加到此 Gateway 並通過它公開其應用程序的內容達成一致。集群運維人員可以在網關上實施 TLS 集中式策略。同時，Store 和 Site 團隊在他們自己的 Namespaces 中運行，但是將他們的 Routes 附加到同一個共享 Gateway，允許他們獨立控制自己的路由邏輯。這種關注點分離允許 Store 隊管理自己的流量拆分部署，同時將集中策略和控制權留給集群運維人員。

這種靈活性技能保持 API 的標準和可移植性，還使其可以適應截然不同的組織模型和實現。

資源模型

note

資源最初將作為 CRD 存在於 networking.x-k8s.io API 組中。未限定的資源名稱將隱含在該 API 組中。

Gateway API 的資源模型中，主要有三種類型的對象：

• GatewayClass：定義了一組具有共同配置和行為的網關。
• Gateway：流量請求端點，流量從這里被翻譯成集群內的服務。
• Route：描述了通過 Gateway 而來的流量如何映射到服務。

GatewayClass

GatewayClass 定義了一組共享共同配置和行為的 Gateway，每個 GatewayClass 由一個控制器處理，但控制器可以處理多個 GatewayClass。

GatewayClass 是一個集群範圍的資源。必須至少定義一個 GatewayClass，Gateway 才能夠生效。實現 Gateway API 的控制器通過關聯的 GatewayClass 資源來實現，用戶可以在自己的 Gateway 中引用該資源。

這類似於 Ingress 的 IngressClass 和 PersistentVolumes 的 StorageClass。在 Ingress v1beta1 中，最接近 GatewayClass 的是 ingress-class 注解，而在 Ingress V1 中，它的作用與 IngressClass 一樣。

kind: GatewayClass
metadata:
  name: cluster-gateway
spec:
  controllerName: "example.net/gateway-controller"

GatewayClass 一般由基礎設施提供商來創建，用戶不需要關注控制器如何實現，只需要了解該 GatewayClass 創建的對應 Gateway 的屬性即可。

Gateway API 的提供者還可以開放了一部分參數配置給網關管理員，管理員可以使用 GatewayClass.spec.parametersRef 字段來配置：

kind: GatewayClass
metadata:
  name: internet
spec:
  controllerName: "example.net/gateway-controller" # 该字段的值应为集群唯一的
  parametersRef:
    group: example.net/v1alpha1
    kind: Config
    name: internet-gateway-config
---
apiVersion: example.net/v1alpha1
kind: Config
metadata:
  name: internet-gateway-config
spec:
  ip-address-pool: internet-vips
  ...

建議使用 GatewayClass.spec.parametersRef 自定義資源配置，不過你也可以使用 ConfigMap。

在剛部署 GatewayClass 後，GatewayClass.status 中的狀態類型為 Accepted 但是 status 為 False，控制器處理完配置後 status 將變為 True，如果在該過程中出現錯誤，那麽會顯示在狀態中，如下所示。

kind: GatewayClass
...
status:
  conditions:
  - type: Accepted
    status: False
    Reason: BadFooBar
    Message: "foobar" is an FooBar.

Gateway

Gateway 描述了如何將流量翻譯到集群內的服務。它定義了一個將流量從不了解 Kubernetes 的地方翻譯到了解 Kubernetes 的地方的方法。例如，由雲負載均衡器、集群內代理或外部硬件負載均衡器發送到 Kubernetes 服務的流量。雖然許多用例的客戶端流量源自集群的 “外部”，但這並不是必需的。

Gateway 定義了對實現 GatewayClass 配置和行為約定的特定負載均衡器配置的請求。該資源可以由運維人員直接創建，也可以由處理 GatewayClass 的控制器創建。

由於 Gateway 規範捕獲了用戶意圖，它可能不包含規範中所有屬性的完整規範。例如，用戶可以省略地址、端口、TLS 設置等字段。這使得管理 GatewayClass 的控制器可以為用戶提供這些缺省設置，從而使規範更加可移植。這種行為將通過 GatewayClass 狀態對象來明確。

一個 Gateway 可以包含一個或多個 Route 引用，這些 Route 引用的作用是將一個子集的流量引導到一個特定的服務上。

Gateway 規範中定義了以下內容：

• GatewayClassName：定義此網關使用的 GatewayClass 對象的名稱。
• Listeners：定義主機名、端口、協議、終止、TLS 設置以及哪些路由可以附加到監聽器。
• Addresses：定義為此 Gateway 請求的網絡地址。 如果以上規範中的配置無法實現，Gateway 將處於錯誤狀態，狀態條件中會顯示詳細信息。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"gateway.networking.k8s.io/v1beta1","kind":"Gateway","metadata":{"annotations":{},"name":"eg","namespace":"default"},"spec":{"gatewayClassName":"eg","listeners":[{"name":"http","port":8080,"protocol":"HTTP"}]}}
  creationTimestamp: "2022-10-22T07:03:28Z"
  generation: 1
  name: eg
  namespace: default
  resourceVersion: "326707757"
  uid: 20f37614-1814-4c4a-b3ee-8d923a1a78f8
spec:
  gatewayClassName: eg
  listeners:
  - allowedRoutes:
      namespaces:
        from: Same
    name: http
    port: 8080
    protocol: HTTP
status:
  addresses:
  - type: IPAddress
    value: 11.11.11.11 # 如果 Envoy Gateway 部署在云上，云会创建一个 LoadBalancer 实例从而获得一个外部 IP，该 IP 为网关 IP
  conditions:
  - lastTransitionTime: "2022-10-22T07:03:28Z"
    message: The Gateway has been scheduled by Envoy Gateway
    observedGeneration: 1
    reason: Scheduled
    status: "True"
    type: Scheduled
  - lastTransitionTime: "2022-10-22T07:04:17Z"
    message: Address assigned to the Gateway, 1/1 envoy Deployment replicas available
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: Ready
  listeners:
  - attachedRoutes: 1
    conditions:
    - lastTransitionTime: "2022-10-22T07:03:30Z"
      message: Listener is ready
      observedGeneration: 1
      reason: Ready
      status: "True"
      type: Ready
    name: http
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute

從上面的示例中我們可以看到 status 中顯示了 Gateway 的狀態，如網關的 IP 地址，監聽器上附著的路由以及更新時間。

Route

Route 對象定義了特定協議的規則，用於將請求從 Gateway 映射到 Kubernetes 服務。

從 v1alpha2 開始，Gateway API 中包含四種 Route 資源類型。對於其他協議，鼓勵使用特定於實現的自定義路由類型。未來可能會向 API 添加新的路由類型。

HTTPRoute

HTTPRoute 用於多路覆用 HTTP 或終止的 HTTPS 連接。它適用於檢查 HTTP 流並使用 HTTP 請求數據進行路由或修改的情況，例如使用 HTTP Header 進行路由或在運行中修改它們。

HTTPRoute 的規範中包括：

• parentRefs：定義此路由要附加到的 Gateway。
• hostnames（可選）：定義用於匹配 HTTP 請求的主機頭的主機名列表。
• rules：定義規則列表以針對匹配的 HTTP 請求執行操作。每條規則由 matches、filters（可選）和 backendRefs（可選）字段組成。

TLSRoute

TLSRoute 用於多路覆用 TLS 連接，通過 SNI 進行區分。它適用於使用 SNI 作為主要路由方法的地方，並且對 HTTP 等高級協議的屬性不感興趣。連接的字節流被代理，無需對後端進行任何檢查。

TCPRoute 和 UDPRoute

TCPRoute（和 UDPRoute）旨在用於將一個或多個端口映射到單個後端。在這種情況下，沒有可用於在同一端口上選擇不同後端的鑒別器（Discriminator），因此每個 TCPRoute 確實需要監聽器上的不同端口。你可以終止 TLS，在這種情況下，未加密的字節流被傳遞到後端。你可以選擇不終止 TLS，在這種情況下，加密的字節流被傳遞到後端。

GRCPRoute

GRPCRoute 用於路由 gRPC 流量。支持 GRPCRoute 的網關需要支持 HTTP/2，而無需從 HTTP/1 進行初始升級，因此可以保證 gRPC 流量正常流動。

Route 類型列表

下面的「路由鑒別器」一欄是指可以使用哪些信息來允許多個 Routes 共享 Listener 上的端口。

對象	OSI 層	路由鑒別器	TLS 支持	目的
HTTPRoute	第 7 層	HTTP 協議中的任何內容	僅終止	HTTP 和 HTTPS 路由
TLSRoute	第 4 層和第 7 層之間的某個位置	SNI 或其他 TLS 屬性	直通或終止	TLS 協議的路由，包括不需要檢查 HTTP 流的 HTTPS
TCPRoute	第 4 層	目的端口	直通或終止	允許將 TCP 流從 Listener 轉發到 Backends
UDPRoute	第 4 層	目的端口	沒有任何	允許將 UDP 流從監聽器轉發到後端
GRPCRoute	第 7 層	gRPC	協議中的任何內容	僅終止

請注意，通過 HTTPRoute 和 TCPRoute 路由的流量可以在網關和後端之間進行加密（通常稱為重新加密）。無法使用現有的 Gateway API 資源對其進行配置，但實現可以為此提供自定義配置，直到 Gateway API 定義了標準化方法。

ReferenceGrant

note

ReferenceGrant 資源仍在實驗階段

ReferenceGrant 可用於在 Gateway API 中啟用跨命名空間引用。特別是，路由可能會將流量轉發到其他命名空間中的後端，或者 Gateway 可能會引用另一個命名空間中的 Secret。

過去，我們已經看到跨命名空間邊界轉發流量是一種理想的功能，但如果沒有 ReferenceGrant 之類的保護措施，就會出現漏洞。

如果從其命名空間外部引用一個對象，則該對象的所有者必須創建一個 ReferenceGrant 資源以顯式允許該引用，否則跨命名空間引用是無效的。

將路由添加到網關

將 Route 附加到 Gateway 表示在 Gateway 上應用的配置，用於配置底層負載均衡器或代理。Route 如何以及哪些 Route 附加到 Gateway 由資源本身控制。Route 和 Gateway 資源具有內置控件以允許或限制它們的連接方式。組織可以同時利用 Kubernetes RBAC，實施有關如何公開 Route 以及在公開在哪些 Gateway 上公開的策略。

如何將 Route 附加到網關以實現不同的組織策略和責任範圍有很大的靈活性。下面是 Gateway 和 Route 可以具有的關系：

一對一：Gateway 和 Route 可以由單個所有者部署和使用，具有一對一的關系。 一對多：Gateway 可以綁定許多 Route，這些 Route 由來自不同命名空間的不同團隊擁有。 多對一：Route 也可以綁定到多個 Gateway，允許單個 Route 同時控制跨不同 IP、負載均衡器或網絡的應用程序。

路由綁定

當 Route 綁定到 Gateway 時，代表應用在 Gateway 上配置了底層的負載均衡器或代理。哪些 Route 如何綁定到 Gateway 是由資源本身控制的。Route 和 Gateway 資源具有內置的控制，以允許或限制它們之間如何相互選擇。這對於強制執行組織策略以確定 Route 如何暴露以及在哪些 Gateway 上暴露非常有用。請看下面的例子。

一個 Kubernetes 集群管理員在 Infra 命名空間中部署了一個名為 shared-gw 的 Gateway，供不同的應用團隊使用，以便將其應用暴露在集群之外。團隊 A 和團隊 B（分別在命名空間 “A” 和 “B” 中）將他們的 Route 綁定到這個 Gateway。它們互不相識，只要它們的 Route 規則互不沖突，就可以繼續隔離運行。團隊 C 有特殊的網絡需求（可能是性能、安全或關鍵業務），他們需要一個專門的 Gateway 來代理。團隊 C 在 “C” 命名空間中部署了自己的 Gateway specialive-gw，該 Gateway 只能由 “C” 命名空間中的應用使用。

不同命名空間及 Gateway 與 Route 的綁定關系如下圖所示。

將路由附加到網關包括以下步驟：

Route 需要在其 parentRefs 字段中引用 Gateway 的條目； Gateway 上至少有一個監聽器允許其附加。

策略附件

策略附件（Policy Attachment）是一種自定義策略資源，例如超時、重試、健康檢查等，這些功能在不同的網關實現中的細節各不相同個，為了 Gateway API 的可移植性，我們將這些工作作為插件附加到資源上。

附加到 Gateway API 資源和實施的策略必須使用以下方法來確保 API 實施之間的一致性。此模式包含三個主要組件：

將策略附加到資源的標準化方法。 支持在策略資源中配置默認值和覆蓋值。 用於說明默認值和覆蓋值應如何交互的層次結構。 這種標準化不僅可以實現一致的模式，還可以讓未來的工具（例如 kubectl 插件）能夠可視化已應用於給定資源的所有策略。

你可以使用 targetRef 字段指定策略附件附加到的資源對象，例如下所示：

apiVersion: networking.acme.io/v1alpha1
kind: RetryPolicy
metadata:
  name: foo
spec:
  default:
    maxRetries: 5
  targetRef:
    group: networking.acme.io
    kind: ExternalService
    name: foo.com

該在例子中，為一個外部服務配置了一個重試策略。你可以給幾乎任何可以發送、接收流量的對象附加策略，例如 GatewayClass、Gateway、Service、Route、Namespace ，不過附加策略的時候，需要注意其優先級。

策略優先級

你可以給策略附件指定 override 和 default 值，其在入口和網格內不同資源上的覆蓋值和默認值的優先級是如下圖所示。

從圖中我們可以看到：

• 覆蓋值：上層覆蓋下層
• 默認值：下層覆蓋上層

引用網關

Route 可以通過在 parentRef 中指定命名空間（如果 Route 和 Gateway 在同一個名稱空間中則該配置是可選的）和 Gateway 的名稱來引用 Gateway。Route 可以使用 parentRef 中的以下字段進一步選擇 Gateway 下的監聽器子集：

SectionName：當設置了 sectionName 時，Route 選擇具有指定名稱的監聽器； Port：當設置了 port 時，Route 會選擇所有指定的監聽端口且協議與此類 Route 兼容的監聽器。 當設置了多個 parentRef 字段時，Route 選擇滿足這些字段中指定的所有條件的監聽器。例如，當 sectionName 和 port 兩者都設置時，Route 選擇具有指定名稱的監聽器並在指定端口上監聽。

限制路由附加

每個 Gateway 監聽器都可以通過以下機制限制其可以附加的路由：

Hostname：如果監聽器上設置了 hostname ，附加路由的 hostnames 中必須至少有一個重疊值。 Namespace：監聽器上的 allowedRoutes.namespaces 字段可用於限制可以附加路由的位置。該 namespaces.from 字段支持以下值： SameNamespace 是默認選項。只有與該網關相同的命名空間中的路由才會被選擇。 All 可選擇來自所有命名空間的 Route。 Selector 意味著該網關將選擇由 Namespace 標簽選擇器選擇的 Namespace 子集的 Route。當使用 Selector 時，那麽 listeners.route.namespaces.selector 字段可用於指定標簽選擇器。All 或 SameNamespace 不支持該字段。 Kind：監聽器上的 allowedRoutes.kinds 字段可用於限制可能附加的路由種類。 如果未指定上述任何一項，網關監聽器將信任從支持監聽器協議的同一命名空間附加的路由。

Gateway - Route 附加示例

在下面的例子中 gateway-api-example-ns1 命名空間中的 my-route Route 想要附加到 foo-gateway 中，不會附加到任何其他 Gateway 上。請注意， foo-gateway 位於與 Gateway 不同的命名空間中。foo-gateway 必須允許來自 gateway-api-example-ns2 命名空間中的 HTTPRoute 附加。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
  namespace: gateway-api-example-ns2
spec:
  parentRefs:
  - kind: Gateway
    name: foo-gateway
    namespace: gateway-api-example-ns1
  rules:
  - backendRefs:
    - name: foo-svc
      port: 8080

foo-gateway 允許 my-route HTTPRoute 附加。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: foo-gateway
  namespace: gateway-api-example-ns1
spec:
  gatewayClassName: foo-lb
  listeners:
  - name: prod-web
    port: 80
    protocol: HTTP
    allowedRoutes:
      kinds: 
        - kind: HTTPRoute
      namespaces:
        from: Selector
        selector:
          matchLabels:
            # 該 label 在 Kubernetes 1.22 中自動添加到所有命名空間中
            kubernetes.io/metadata.name: gateway-api-example-ns2

對於一個更寬松的示例，下面的網關將允許所有 HTTPRoute 資源從帶有 expose-apps: true 標簽的命名空間附加。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: gateway-api-example-ns1
spec:
  gatewayClassName: foo-lb
  listeners:
  - name: prod-web
    port: 80
    protocol: HTTP    
    allowedRoutes:
      kinds: 
        - kind: HTTPRoute
      namespaces:
        from: Selector
        selector:
          matchLabels:
            expose-apps: "true"

組合類型

GatewayClass、Gateway、xRoute 和 Service 的組合將定義一個可實現的負載均衡器。下圖說明了不同資源之間的關系。

請求流程

使用反向代理實現的網關的一個典型的客戶端 / 網關 API 請求流程如下：

客戶端向 http://foo.example.com 發出請求。 DNS 將該名稱解析為 Gateway 地址。 反向代理在 Listener 上接收請求，並使用 Host header 來匹配 HTTPRoute。 可選地，反向代理可以根據 HTTPRoute 中的 match 規則執行請求 header 和 / 或路徑匹配。 可選地，反向代理可以根據 HTTPRoute 中的 filter 規則修改請求，即添加 / 刪除 header。 最後，反向代理可以根據 HTTPRoute 中的 forwardTo 規則，將請求轉發到集群中的一個或多個對象，即 Service。 TLS 配置 我們可以在 Gateway 監聽器上配置 TLS，還可以跨命名空間引用。

首先我們先說明幾個術語：

• 下遊：客戶端和網關之間的鏈接。
• 上遊：網關與路由器指定的後端服務之間的鏈接。

通過 Gateway API 可以分別對上遊或下遊的 TLS 進行配置。

根據監聽器協議，支持不同的 TLS 模式和路由類型，如下表所示。

監聽器協議	TLS 模式	支持的路由類型
TLS	直通	TLSRoute
TLS	終止	TCPRoute
HTTPS	終止	HTTPRoute

請注意，在Passthrough（直通）TLS 模式下，沒有 TLS 設置生效，因為來自客戶端的 TLS 會話不會在網關處終止。本文的其余部分假定 TLS 在網關處終止，這是默認設置。

下遊 TLS

下遊 TLS 設置使用網關級別的監聽器進行配置。

監聽器和 TLS

監聽器基於每個域或子域公開 TLS 設置。監聽器的 TLS 設置適用於滿足 hostname 條件的所有域。

在以下示例中，default-cert Gateway 為所有請求提供 Secret 資源中定義的 TLS 證書。盡管該示例涉及 HTTPS 協議，但也可以將相同的功能用於 TLS-only 協議以及 TLSRoutes。

listeners:
- protocol: HTTPS # Other possible value is `TLS`
  port: 443
  tls:
    mode: Terminate # If protocol is `TLS`, `Passthrough` is a possible mode
    certificateRef:
      kind: Secret
      group: ""
      name: default-cert

如果 hostname.match 設置為Exact，則 TLS 設置僅適用於在 hostname.name 中設置的特定主機名。

示例 具有不同證書的監聽器 在下面的示例中，配置 Gateway 服務於 foo.example.com 和 bar.example.com 域。這些域的證書在 Gateway 中指定。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: tls-basic
spec:
  gatewayClassName: acme-lb
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      certificateRefs:
      - kind: Secret
        group: ""
        name: foo-example-com-cert
  - name: bar-https
    protocol: HTTPS
    port: 443
    hostname: bar.example.com
    tls:
      certificateRefs:
      - kind: Secret
        group: ""
        name: bar-example-com-cert

通配符 TLS 監聽器

在下面的示例中，Gateway 為 *.example.com 和 foo.example.com 域配置了不同的通配符證書。由於特定匹配具有優先權，所有對 foo.example.com 的請求將使用 foo-example-com-cert，所有對 exmaple.com 的其他請求使用 wildcard-example-com-cert 證書。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: wildcard-tls-gateway
spec:
  gatewayClassName: acme-lb
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      certificateRefs:
      - kind: Secret
        group: ""
        name: foo-example-com-cert
  - name: wildcard-https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      certificateRefs:
      - kind: Secret
        group: ""
        name: wildcard-example-com-cert

跨命名空間證書引用

在此示例中，配置 Gateway 引用不同命名空間中的證書。在目標命名空間中創建 ReferenceGrant 以允許跨命名空間引用。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: cross-namespace-tls-gateway
  namespace: gateway-api-example-ns1
spec:
  gatewayClassName: acme-lb
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      certificateRefs:
      - kind: Secret
        group: ""
        name: wildcard-example-com-cert
        namespace: gateway-api-example-ns2

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: ReferenceGrant
metadata:
  name: allow-ns1-gateways-to-ref-secrets
  namespace: gateway-api-example-ns2
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: Gateway
    namespace: gateway-api-example-ns1
  to:
  - group: ""
    kind: Secret

擴展

網關 TLS 配置提供了一個 options 映射來為特定於實現的功能添加額外的 TLS 設置。此處可能包含的一些功能示例是 TLS 版本限制或要使用的密碼。

擴展點

API 中提供了一些擴展點，以靈活處理大量通用 API 無法處理的用例。

以下是 API 中擴展點的摘要。

• BackendRefs：此擴展點應用於將流量轉發到核心 Kubernetes 服務資源以外的網絡端點。例如 S3 存儲桶、Lambda 函數、文件服務器等。 HTTPRouteFilter：HTTPRoute 中的這種 API 類型提供了一種掛鉤 HTTP 請求的請求 / 響應生命周期的方法。
• 自定義路由：如果上述擴展點都不能滿足用例的需要，實施者可以選擇為 API 當前不支持的協議創建自定義路由資源。自定義路由類型需要共享與核心路由類型相同的字段。這些包含在 CommonRouteSpec 和 RouteStatus 中。